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ABSTRACT 

The  structure  of  separately  compiled  procedures  in  the  GLYPNIR 
compiler  and  the  use  of  storage  areas  common  to  separately  compiled  program 
units  are  described  and,  for  the  benefit  of  those  who  may  wish  to  modify  the 
compiler,  a  description  is  given  of  the  current  implementation  of  both  inter- 
nal and  separately  compiled  subroutines. 
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1.   INTRODUCTION 

GLYPNIR  is  a  high-level  block  structured  language  for  ILLIAC  IV 
programming.   The  GLYPNIR  compiler  is  run  on  the  E-65OO  and  produces  ILLIAC  IV 
assembler  code.   This  is  then  input  to  the  assembler  (ASK),  also  run  on  the 
B65OO,  which,  in  turn,  produces  exacutable  ILLIAC  IV  machine  code.   This 
paper  describes  facilities  recently  implemented  in  the  GLYPNIR  compiler  which 
allow  compilation  and  linkage  of  separately  compiled  GLYPNIR  subroutines  and 
which  provide  named  common  storage  areas  shared  among  separately  compiled 
program  segments. 

The  implementation  of  separately  compiled  GLYPNIR  subroutines 
(heretofore  synonymous  with  external  GLYPNIR  subroutines)  should  provide  the 
GLYPNIR  user  with  several  benefits.   It  will  now  be  possible  to  write  sub- 
sections of  GLYPNIR  programs  and  fully  debug  them  for  incorporation  into 
larger  programs  at  a  later  time  without  having  to  recompile  those  subsections 
each  time  the  main  program  is  modified.   It  appears  as  if  the  B65OO  will  be 
overworked  in  the  ILLIAC  system,  but  reducing  the  compilation  time  of  GLYPNIR 
programs  should  ease  this  strain  somewhat.   Furthermore,  it  will  be  possible 
to  code  library  routines  in  GLYPNIR  and  eliminate  the  necessity  for  writing 
complex  packages  in  ASK.   (For  the  time  being,  however,  external  GLYPNIR 
subroutines  may  be  called  only  from  other  GLYPNIR  programs.)  Finally,  a 
facility  has  been  provided  which  makes  linkage  to  a  non-GLYPNIR  subroutine 
fairly  easy  to  specify  in  a  GLYPNIR  program. 

Little  space  has  been  devoted  here  to  a  discussion  of  historical 
precedent  for  subroutine  linkage  methods  or  for  the  method  of  implementation 
chosen.   But  the  problem  was  not  simply:   Given  an  ILLIAC  IV,  how  does  one 


provide  separately  compiled  subroutines  and  common  facilities?   The  problem 
was:   Given  an  ILLIAC  IV  and  a  GLYPNIR  compiler,  how  does  one  add  these 
facilities  to  the  existing  compiler  without  necessitating  major  revisions  to 
the  structure  of  the  compiler?   The  options  available  for  accomplishing 
this  task  in  a  reasonable  amount  of  time,  yet  providing  the  user  with  a  good 
deal  of  flexibility,  were  quite  limited.   In  some  areas,  particularly  in  the 
area  of  common  storage  treatment,  a  more  optimal  approach  might  have  been 
used.  However,  since  from  the  user's  point  of  view  there  was  little  differ- 
ence in  terms  of  efficiency  and  programming  flexibility,  the  GLYPNIR  staff 
felt  that  optimal  solutions  were  not  justified  with  respect  to  the  several 
extra  months  of  work  required. 

Chapter  2  deals  primarily  with  the  specification  and  use  of  separ- 
ately compiled  GLYPNIR  subroutines  and  is  of  interest  to  the  general  GLYPNIR 
user.   A  knowledge  of  other  parts  of  the  GLYPNIR  language  and  familiarity  with 
ILLIAC  IV  architecture  are  assumed.   (Lawrie  [1]  provides  a  good  introduction 
to  the  GLYPNIR  language.) 

Chapter  3  deals  specifically  with  the  ways  in  which  subroutines, 
both  internally  and  externally  compiled,  have  been  implemented  in  the  compiler 
As  such,  this  chapter  will  not  be  particularly  useful  for  the  general  user. 

Internal  subroutines  in  GLYPNIR  are  similar  to  ALGOL  procedures  in 
their  declaration,  and  similar  to  FORTRAN  subroutines  in  their  use.   The 
preparatory  work  for  this  paper  consisted  of  implementing  separately  compiled 
subroutines  and  named  common  facilities.   However,  since  the  compiler  routines 
responsible  for  establishing  external  subroutine  linkages  are  the  same  ones 
responsible  for  internal  subroutine  linkages,  and  since  no  documentation 
existed  on  either  aspect,  I  chose  to  deal  with  these  as  well.   (Lawrie  and 


Layman  [3]   provides  a  good  overall  description  of  the   structure  of  the  GLYPNIR 
compiler. ) 


2.   THE  SPECIFICATION  OF  SEPARATELY  COMPILED  SUBROUTINES  IN  GLYPNIR 

2.1  An  Over view 

The  use  and  declaration  of  external  subroutines  in  GLYPNIR  are  quite 
similar  to  those  of  internal  subroutines.   Familiarity  with  these  would  assist 
the  reader  in  following  discussions.   (See  Chapters  9  and  10  in  Lawrie  [1].) 
The  subroutine  call  on  an  external  subroutine  in  GLYPNIR  is  of  exactly  the 
same  form  as  a  call  on  an  internal  subroutine.   Like  internal  subroutines, 
external  subroutines  may  be  used  as  function  designators  if  they  have  been 
declared  with  a  type.   The  same  restrictions  are  placed  upon  them;  recursive 
use  of  subroutines  is  not  allowed.   If  the  subroutine  is  declared  with  a  type, 
the  use  of  the  subroutine  identifier  within  the  subroutine  body  is  equivalent 
to  the  use  of  a  simple  variable  with  the  same  type. 

There  are  two  aspects  of  external  subroutine  declarations,  the  first 
of  which  is  the  subroutine  itself.   The  external  subroutine  is  simply  a  GLYP- 
NIR program  with  a  subroutine  heading  at  the  beginning  which  must  be  compiled 
with  its  own  control  cards  like  any  GLYPNIR  program.   Compiling  more  than  one 
subroutine  in  a  single  run  is  not  possible  at  this  time  but  may  be  allowed  at 
a  later  date.   The  external  subroutine  may  have  its  own  internal  subroutines 
and  may,  in  turn,  reference  other  external  subroutines.   All  variables  used 
in  the  subroutine  must  be  declared  in  it,  either  as  parameters  in  its  heading 
or  as  variables  declared  in  the  usual  fashion;  i.e.,  no  variables  may  be  glo- 
bal to  it. 

The  second  aspect  of  external  subroutines  is  the  external  entry 
declaration  in  the  calling  program.   Since  the  subroutine  is  compiled  separ- 
ately from  the  calling  program,  the  compiler  must  be  instructed  where  to 


transfer  control  and  where  to  pass  the  parameters  when  performing  the  linkage. 
The  external  entry  declaration  probides  this  information  and  is  quite  similar 
to  an  internal  subroutine  declaration  with  no  body.   GLYPNIR  constructs  entry 
point  names  and  ASK  variable  names  from  the  first  five  characters  of  the  sub- 
routine identifier  and,  therefore,  the  first  five  characters  in  the  name  of 
any  external  subroutines  used  in  the  execution  of  a  GLYPNIR  program  must  be 
unique . 

Data  communication  between  separately  compiled  GLYPNIR  program  seg- 
ments is  accomplished  in  two  ways:   variables  can  be  passed  as  parameters  or 
they  can  be  declared  in  common  storage  areas  which  are  shared  between  the 
segments.   There  are  instances  where  this  second  form  of  communication  is 
advantageous;  these  will  be  discussed  later  in  this  chapter. 

A  simple  method  for  establishing  linkages  to  non-GLYPNIR  subroutines 
from  GLYPNIR  programs  is  also  presented  here.   Use  of  this  facility,  however, 
requires  some  knowledge  of  the  way  in  which  subroutine  linkages  are  accom- 
plished and  a  thorough  understanding  of  the  AS  construct  in  variable  declara- 
tions. 

2.2  The  External  Subroutine 

GLYPNIR  programs  may  be  main  programs  or  subroutines: 
<GLYPNIR  program>: : =  <external  subroutine  heading>  <unlabelled 

block>  |  <unlabelled  block> 

The  presence  of  <external  subroutine  heading>  indicates  to  the  compiler  that 

the  program  is  to  be  compiled  as  a  subroutine,  and  no  other  control  information 

is  necessary. 
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SYNTAX: 


EXAMPLE: 


<external  subroutine  heading>: : =  SUBROUTINE  <subroutine  identifier^ 
<external  formal  parameter  part>;  |  <type>  SUBROUTINE  <sub- 
routine  identifier>  <external  formal  parameter  part>; 

<subroutine  identif ier>: : =  <identif ier>  |  <identif ier>  AS 
<identifier> 

<external  formal  parameter  part>: : =  (<external  formal  parameter 
specification  list>)  |  <empty> 

<external  formal  parameter  specification  list>::=  <external  formal 
parameter  specification>  |  <external  formal  parameter  specifi- 
cation list>,<external  formal  parameter  specification> 

<external  formal  parameter  specif ication>: :=  <type>  <variable 

identifier>  |  <type>  <variable  identifier>  AS  <identifier> 

CINT  SUBROUTINE  ALPHA  AS  CAR2 
(PC POINT  PNT  AS  RGX, 
CINT  INDEX, 
BOOLEAN  TOG); 
BEGIN 

<program  body> 
END. 

Notice  that  the  specification  of  formal  parameters  is  made  in  the 
parameter  list;  in  the  compilation  of  the  subroutine,  those  specifications  are 
treated  like  any  variable  declaration.   Specification  of  a  parameter  as  an 
output  (OUT)  parameter,  corresponding  to  a  call-by-name  parameter  in  ALGOL,  is 
not  necessary  here,  but  that  information  is  needed  in  the  external  subroutine 


entry  declaration  in  the  calling  program. 

Notice  also  that  specifying  a  formal  parameter  as. a  vector  is  not 
allowed.   Vectors  can  be  passed  as  parameters,  however,  in  the  same  fashion 
that  they  can  he  passed  as  parameters  to  internal  subroutines  (see  Appendix  C 
of  this  document)  or  they  can  be  passed  to  external  subroutines  by  declaring 
them  in  a  common  storage  area.   The  programmer  must  be  aware  in  either  case 
that  a  call-by-name  is  implied;  there  is  no  intrinsic  way  to  pass  a  vector  by 
value  in  GLYPNIR. 

If  the  AS  construct  is  used  in  the  specification  of  a  formal  para- 
meter or  subroutine  identifier  in  the  case  of  a  typed  subroutine,  the  identi- 
fier following  AS  must  specify  a  hardware  register,  e.g.,  RGA,  CAR1,  ADBte. 
In  declaring  a  variable  AS  as  hardware  register,  any  reference  to  that  vari- 
able in  the  program  implies  a  reference  to  the  contents  of  that  register, 
and  the  contents  of  the  register  are  considered  to  be  of  the  same  type  (e.g., 
PE  REAL,  CU  ALPHA)  as  the  type  declared  for  the  variable.   When  formal  para- 
meters are  declared  AS  hardware  registers,  during  the  process  of  subroutine 
linkage  the  values  of  the  corresponding  actual  parameters  are  placed  in  those 
registers  before  program  control  is  passed  to  the  subroutine  (see  sections 
4.2.3  and  12.2  of  Lawrie  [1]  for  a  full  explanation).   Table  1  shows  the  types 
allowed  with  variables  declared  AS  hardware  registers.   The  programmer  should 
also  be  aware  that  ADB  storage  is  available  for  this  purpose  when  formal 
parameters  are  CU  variables. 

2. 3  The  External  Subroutine  Entry  Declaration 

When  a  GLYPNIR  program  must  be  linked  to  a  separately  compiled  sub- 
program, the  compiler  must  be  informed  where  the  values  of  the  actual  para- 


TABLE  1 
HARDWARE  REGISTERS 


Allowed  T 


Register 

Implicit 

type 

RGA 

PALPHA 

RGB 

n 

RGC1 

it 

RGD 

it 

RGR 

ii 

RGS 

it 

RGX 

PCPOINT 

RGE 

BOOLEAN 

RGE1 

it 

RGF1 

ti 

RGF11 

tt 

RGG 

tt 

RGH 

ti 

RGI 

tt 

RGJ 

ti 

CARO2 

it 

CAR1 

CALPHA 

CAR2 

k 
CAR3 

CNPOINT 

CALPHA 

MODE2 

BOOLEAN 

PEN3 

PINT 

NOTES:   1. 

It  is  not  po^ 

2. 

Stores  to  MOI 

§00 


/ 


/    /    / 


/ 
/ 
/ 
/ 
/ 
/ 
/ 
/ 
/ 
/ 

• 

/ 
1/ 


/  implies  type  is  allowed 
Die  to  load  to  these  registers. 
Stores  to  MODE  or  CARO  cause  the  E  and  El  hits  to  he  set 
as  well.   Formal  parameters  should  not  he  AS-ed  to  these 
registers.   Changes  to  MODE  should  he  made  hefore  subroutine 
call  or  within  subroutine  hody. 
PEN  is  really  a  pseudo  register.   PEN  Is  initialized  to  the 


TABLE  1  (continued! 


PE  number  at  the  beginning  of  execution.  '  Formal  para- 
meters cannot  be  AS-ed  to  this  register. 
k.      Return  address  passed  to  subroutine  in  ACAR3  and  therefore 
it  must  not  be  used  as  a  formal  parameter. 
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meters  are  to  be  stored  and  where  to  transfer  program  control.   This  informa- 
tion is  specified  in  the  external  subroutine  entry  declaration  which,  in  GLYP- 
NIR,  may  appear  anywhere  a  declaration  is  allowed. 
SYNTAX: 

<external  subroutine  entry  declaration^ : =  EXTERNAL  SUBROUTINE 

<subroutine  identifier>  <formal  parameter  part>  <entry  part> 
<filename  part>  |  EXTERNAL  <type>  SUBROUTINE  Subroutine 
identifier>  <formal  parameters  part>  <entry  part>  <filename 
part> 
<subroutine  identifier>: :=  <identifier>  |  <identifier>  AS  <identi- 

fier> 
<formal  parameter  part>: : =  (<formal  parameter  specification  list>) 

|  <empty> 
<formal  parameter  specification  list>::=  <formal  parameter  specif i- 
cation>  |  <formal  parameter  specification  list>,<formal  para- 
meter specification> 
<formal  parameter  specification^  : =  <type>  <variable  identifier>  | 

<type>  OUT  <variable  identifier> 
<variable  identifier>: : =  <identifier>  |  <identifier>  AS  <identifier> 
<entry  part>::=  ENTRY  =  <identifier>  |  <empty> 
<f ilename  part>: : =  FILENAME  =  <string>  |  <empty> 
EXAMPLE: 

EXTERNAL  SUBROUTINE  S; 

EXTERNAL  CINT  SUBROUTINE  ALPHA  AS  CAR2 

(PCPOINT  PNT  AS  RGX, 

CINT  INDEX, 
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BOOLEAN  TOG); 

EXTERNAL  PREAL  SUBROUTINE  FUNCTIONX  AS  RGA 
(PREAL  ARG  AS  RGA) 
ENTRY  =  XSTART 
FILENAME  =  "MYFILES/ASKFUNCTION"; 

Notice  that  use  of  the  AS  construct  in  connection  with  external 
subroutines  requires  that  the  identifier  following  AS  must  be  a  hardware 
register.   Notice  also  that  the  declaration  of  a  parameter  as  an  output  para- 
meter (OUT)  is  important  here,  since  it  is  the  calling  program  which  is  res- 
ponsible for  assigning  the  output  values  to  those  actual  parameters  upon  exit 
from  the  subroutine. 

The  subroutine  identifier  and  parameter  specifications  must  corre- 
spond with  those  of  the  associated  external  subroutine  heading  on  a  one-to- 
one  basis  in  type  and  AS-ed  to  the  same  register  if  the  AS  construct  is  used. 

The  presence  of  <entry  part>  explicitly  indicates  that  the  external 
subroutine  is  a  non-GLYPNIR  program  and  should  never  be  used  in  the  external 
entry  declaration  for  a  GLYPNIR  subroutine.   (Use  of  the  <entry  part>  con- 
struct is  explained  in  Section  2.6  of  this  Chapter.) 

The  <filename  part>  construct  is  provided  for  use  in  conjunction 
with  the  GLYPNIR  control  option  ZIP.   In  compiling  a  main  program  with  the  ZIP 
option  turned  on,  the  compiler  will  generate  the  necessary  control  cards  to 
assembler,  collect  and  load  the  compiled  program.   By  specifying  FILENAME  = 
<string>,  where  <string>  is  simply  the  name  of  the  file  containing  the  assem- 
bled subroutine  code,  the  compiler  is  able  to  generate  instructions  for 
including  that  with  the  main  program  code  file  at  collection  time.   The  pres- 
ence of  <filename  part>  in  an  external  entry  declaration  in  the  body  of  an 
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external  subroutine  is  allowed,  but  meaningless  (see  Section  2.8  of  this 
Chapter) . 

2.k     The  External  Subroutine  Call 
SYNTAX: 

<subroutine  call>::=  <subroutine  identifier>  <actual  parameter  part> 

<actual  parameter  part>: : =  (<actual  parameter  list>)  |  <empty> 

<actual  parameter  list>::=  <actual  parameter>  |  <actual  parameter 
list>,<actual  parameter> 

<actual  parameter>: : =  <variable  identifier>  |  <expression>  j  <empty> 

<subroutine  statement>: : =  <subroutine  call> 

<function  designator>: : =  <subroutine  call> 

As  might  be  expected,  the  syntaxes  for  calls  to  external  and  internal 
subroutines  are  identical.   The  actual  parameters  of  the  subroutine  call  cor- 
respond directly  to  the  formal  parameters  appearing  in  the  external  subroutine 
entry  declaration.   An  empty  actual  parameter  is  equivalent  to  the  occurence  of 
a  literal  zero  (FALSE  if  Boolean).   If  the  number  of  actual  parameters  is  less 
than  that  of  the  declared  formal  parameters,  the  remaining  unspecified  actual 
parameters  are  considered  to  be  empty  and  equivalent  to  the  occurence  of  zero 
or  FALSE. 

If  the  actual  parameter  corresponding  to  a  formal  parameter  declared 
as  OUT  is  a  simple  variable,  that  variable  will  hold  the  value  last  held  by 
the  corresponding  parameter  in  the  subroutine  when  the  subroutine  is  exited. 
In  other  words,  the  effect  is  the  same  as  that  of  using  a  variable  as  a  call- 
by-name  parameter  in  ALGOL.   Should  the  actual  parameter  corresponding  to  an 
output  parameter  be  an  expression  or  empty,  the  parameter  will  be  considered 
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as  an  input  parameter  only  for  that  particular  subroutine  call. 

If  the  type  of  the  actual  parameter  differs  from  that  of  the  for- 
mal parameter,  the  value  of  the  actual  parameter  will  be  converted  to  the 
type  of  the  formal  parameter,  if  such  conversion  is  legal.   Table  2  summar- 
izes the  rules  for  such  conversions. 

If  any  of  the  formal  parameters  in  an  external  entry  declaration 
are  declared  AS  hardware  registers,  all  the  actual  parameters  in  calls  to 
that  subroutine  must  be  simple  variables  of  the  same  type  as  the  formal  para- 
meter, or  empty.   The  reason  for  this  is  that  in  evaluating  expressions  or 
in  performing  type  conversions,  the  compiler  uses  certain  hardware  registers, 
and  it  might  overwrite  a  parameter  specified  as  a  hardware  register  which 
has  been  already  processed.   Consider  the  following  example: 

PE  REAL  X,Y; 

EXTERNAL  SUBROUTINE 

S(PE  REAL  A  AS  RGA,  PE  INTEGER  B); 

S(X,Y) 
The  call  on  S  would  result  in  an  error  condition  due  to  the  follow- 
ing actions: 

1.  The  compiler  would  process  actual  parameter  X.   It  would 
see  that  X  is  of  the  same  type  as  formal  parameter  A,  and  would 
simply  write  the  contents  of  X  into  RGA. 

2.  The  compiler  would  then  attempt  to  process  actual  parameter 
Y.   It  would  notice  that  a  type  conversion  from  REAL  to  INTEGER  is 
required,  and  that  to  perform  that  conversion  RGA  must  be  free. 
Since  RGA  is  not  free,  an  error  condition  would  result. 
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TABLE  2 
PARAMETER  CONVERSION,  ACTUAL  AND  FORMAL  PARAMETER  TYPE  DIFFERENCES 


Actual  Type 


Formal  Type 


Real 

Integer 

Alpha 

Boolean 

Confined  Pointer 

Non-Confined  Pointer 


Confined  Non-Confined 
Real  Integer  Alpha  Boolean  Pointer Pointer 


2 

2 

X 

X 

X 

X 

X 

X 

X 
X 
X 


X 
X 
X 

X 
X 


X 
X 
X 
X 


X 
X 
X 
X 

X 


(Blank — no  conversion  necessary;  X  =  not  allowed.) 

1.  Usual  conversion 

2.  AP  is  rounded  and  truncated.   If  the  value  of  the  AP  is  too  large 

for  U 8-bit  fixed  point  representation,  an  overflow  condition  results. 


15 
This  is  not  a  manditory  requirement,  since  this  sort  of  problem 
would  not  arise  in  all  cases  and  the  compiler  does  make  a  fairly  thorough 
check  of  register  misuse  in  parameter  assignment.   However,  unless  the  pro- 
grammer has  a  good  deal  of  experience,  he  would  be  wise  to  follow  the  practice 
of  using  only  simple  variables  of  the  correct  type  for  actual  parameters  cor- 
responding to  formal  parameters  declared  AS  registers. 

2.5  The  Declaration  and  Use  of  Common  Storage  Areas 

A  FORTRAN-like  named  common  facility  is  available  in  GLYPNIR  which 
makes  it  possible  for  a  GLYPNIR  program  segment  to  share  memory  locations  of 
variables  declared  in  the  common  blocks  with  every  other  separately  compiled 
program  segment  having  a  declaration  for  the  same  common  block. 
SYNTAX: 

<common  block>: : =  COMMON  <common  block  name>;  <common  variable 
declaration  list>;  ENDCOMMON; 

<common  block  name>: : =  <identif ier>  |  <empty> 

<common  variable  declaration  list>::=  <common  variable  declaration> 
<common  variable  declaration  list>;  <common  variable 
declaration> 

<common  variable  declaration^ : =  <type>  <entity>  <variable  list> 

<variable  list>: : =  <identifier>  |  <variable  list>,<identifier> 

<entity>::=  VECTOR  |  <empty> 

<type>  may  be  any  of  the  following: 

PE  ALPHA  PALPHA 

PE  INTEGER  PINT 

PE  REAL  PREAL 
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PE  CONFINED  POINTER  PCPOINT 

CU  ALPHA  CALPHA 

CU  INTEGER  CINT 

CU  REAL  CREAL 

CU  NONCONFINED  POINTER        CNPOINT 

BOOLEAN 

Common  block  declarations  may  appear  in  GLYPNIR  anywhere  a  declar- 
ation is  legal,  and  more  than  one  common  "block  declaration  may  occur  in  a 
GLYPNIR  program  or  in  an  external  subroutine.   The  maximum  number  of  common 
blocks  that  can  be  shared  among  a  GLYPNIR  main  program  and  all  of  its  exter- 
nal subroutines  is  seven.   Furthermore,  all  common  blocks  must  be  declared  in 
the  main  program,  even  if  they  are  needed  only  as  common  storage  between  two 
of  the  subroutines. 

If  only  one  common  block  is  needed  among  the  main  program  and  sub- 
routines, that  block  need  not  be  named  (<common  block  name>  may  be  empty>); 
otherwise  the  blocks  must  be  named.  GLYPNIR  uses  the  first  five  characters 
of  the  common  block  name  to  contruct  the  ASK  variable  names  generated  for 
the  declared  common  variable  and,  therefore,  all  identifiers  used  in  naming 
the  common  blocks  and  external  subroutines  must  be  unique  in  the  first  five 
characters. 

Within  the  program,  a  variable  declared  in  a  common  block  should  be 
treated  as  any  variable  declared  in  the  normal  fashion.   When  corresponding 
common  blocks  are  declared  in  their  respective  programs,  however,  the  prog- 
rammer must  be  sure  that  all  variables  in  the  block  are  declared' in  the  same 
order  and  of  the  same  type  as  their  counterparts  in  other  programs. 
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Vectors  may  be  declared  in  common  blocks  and  are  equivalent  to 
declaring  n  +  1  simple  variables  where  n  is  the  dimension  of  the  vector. 
Furthermore,  a  vector  may  be  declared  in  a  common  block  where  n  +  1  simple 
variables  are  declared  in  the  same  block  in  a  different  separately  compiled 
segment.   For  example,  if  in  one  declaration  we  had: 

CINT  VECTOR  CVI[2]; 
and  if  in  the  corresponding  declaration  in  another  segment  we  had: 

CINT  CVA,  CVB,  CAC,  CVD; 
then  CVI[0]  and  CVA  would  refer  to  the  same  location,  as  would  CVI[1]  and 
CVB,  etc. 

Common  blocks  in  subroutines  may  have  fewer  PE  variables  declared 
in  them  than  their  counterparts  in  the  main  program,  but  in  no  case  may  there 
be  more.   The  same  is  true  for  CU  and  Boolean  variables.   Declarations  for 
PE,  CU,  and  Boolean  variables  may  be  mixed  but  it  is  good  practice  to  declare 
all  variables  of  each  respective  type  together  within  the  common  block  dec- 
laration, simply  to  provide  programming  clarity.   If  more  variables  are  dec- 
lared in  a  subroutine  common  block  than  in  its  MAIN  counterpart,  the  compiler 
cannot  detect  the  error,  and  the  effect  will  probably  be  an  alteration  of 
the  values  of  variables  in  the  main  program  or  in  other  common  blocks. 

Consider  the  following  example  where  we  have  a  main  program  and  two 
separately  compiled  subroutines,  SI  and  S2,  and  see  Table  3- 

BEGIN  foMAIN  PROGRAM 
EXTERNAL  SUBROUTINE  SI J 
EXTERNAL  SUBROUTINE  S2; 
COMMON  CBA 

PREAL  X,  Y,  Zj 
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BOOLEAN  BM; 

CINT  CI,  CJ; 
ENDCOMMON; 
COMMON  CBB; 

PINT  A,  B,  C,  D,  E; 
ENDCOMMON; 


END. 
SUBROUTINE  SI 
COMMON  CBA; 

PREAL  Q,  R;  PINT  S; 

BOOLEAN  BS1; 

CINT  CI,  CJ; 
ENDCOMMON; 

END. 


SUBROUTINE  S2; 
COMMON  CBA; 

PREAL  X,  Y,  Z; 

BOOLEAN  BS2; 

CINT  CI; 
ENDCOMMON; 
COMMON  CBB; 

PINT  VECTOR  VI [U] 
ENDCOMMON; 


END. 

In  some  instances  it  is  preferable  to  communicate  data  to  subrou- 
tines via  common  rather  than  as  parameters,  especially  in  the  case  where  the 
same  variables  are  passed  as  actual  parameters  in  each  call.   Using  common  is 
more  efficient  since  the  time  consumed  in  passing  the  values  of  the  parameters 
is  eliminated.   And  although  it  is  not  difficult  to  pass  vectors  as  para- 
meters, it  is  much  easier  to  use  vectors  declared  in  common  blocks.   Finally, 
in  the  case  where  an  ASK  subroutine  is  written  for  a  GLYPNIR  program,  it  is 
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a  fairly  simple  matter  for  that  subroutine  to  reference  common  variables 
(see  Section  2.6  of  this  Chapter). 

2.6  Linkage  to  Non-GLYPNIR  External  Subroutines 

When  the  ENTRY  construct  is  used  in  an  external  subroutine  entry 
declaration,  it  is  assumed  that  a  linkage  to  a  non-GLYPNIR  subroutine  is 
desired  and,  as  such,  a  special  restriction  is  placed  on  the  formal  para- 
meters:  they  must  all  be  declared  AS  hardware  registers.   This  feature  was 
implemented  for  linking  to  ASK  subroutines,  "but  linkage  to  subroutines  writ- 
ten in  another  language  might  be  possible,  depending  on  how  separately  com- 
piled subroutines  are  handled  in  that  language. 

The  effect  of  the  call  on  a  subroutine  declared  in  this  fashion  is 
that  the  values  of  any  parameters  are  placed  in  their  assigned  registers,  and 
a  branch  to  the  label  specified  in  <entry  part>  is  performed.   The  return 
address  is  passed  to  the  subroutine  in  ACAR3,  and  the  subroutine  is  responsi- 
ble for  saving  that  address  for  later  use  when  a  return  to  the  calling  prog- 
ram is  desired.   Also,  the  subroutine  must  insure  that  ACARO  contains  the 
current  mode  upon  returning  control  to  the  calling  program.  When  the  sub- 
routine is  entered,  the  E  and  El  bits  and  ACARO  (containing  a  representation 
of  the  E  and  El  bits)  are  left  unchanged;  i.e.,  the  mode  pattern  remains  the 
same.   The  programmer  is  free  to  alter  the  mode  within  the  subroutine,  but 
ACARO  must  always  reflect  these  changes  when  the  subroutine  is  exited. 

An  ASK  subroutine  used  in  this  fashion  should  be  of  the  approximate 
form: 

BEGIN 

<declaration  of  subroutine  variable  storage> 
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<save  contents  of  ACAR3  (return  address)  somewhere> 

<exe cut able  code> 

<restore  return  address  to  ACAR3> 

EXCHL(3)  $ICR; 

END. 

In  the  example,  <entry  identifier>  is  the  same  identifier  that 
follows  the  "ENTRY="  in  the  external  subroutine  entry  declaration  in  the 
calling  program.  Appendix  B  contains  a  sample  ASK  subroutine  to  be  used 
■with  a  GLYPNIR  program. 

It  is  possible  for  ASK  subroutines  to  reference  variables  declared 
in  common  blocks  in  the  calling  program.   First,  external  declarations  in 
the  ASK  subroutine  must  be  made  of  the  base  addresses  of  the  PE,  CU,  and 
Boolean  storage  blocks.   To  determine  the  names  of  these  blocks,  append  the 
first  five  characters  of  the  block  name  to  the  letters  P,  C,  and  B  respec- 
tively.  For  example,  if  the  subroutine  is  to  reference  variable  declared 
in  a  common  block  named  AREA,  there  should  appear  in  the  subroutine  the 
statement: 

EXTERNAL  PAREA,  CAREA,  BAREA; 
These  represent  the  base  addresses  for  those  storage  areas.   To  reference  the 
first  CU  variable  declared  in  the  block,  one  would  use  the  address  CAREA  +  0, 
for  the  second,  CAREA  +  1,  etc.   The  same  is  true  of  the  PE  and  Boolean 
variables.   Needless  to  say,  the  contents  of  those  locations  should  be 
treated  as  quantities  of  the  same  type  (POINTER,  REAL,  etc.)  as  their  declar- 
ations in  the  common  block. 

One  useful  feature  of  this  method  is  the  ability  to  link  to  the 
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available  mathematical  subroutines  like  gamma  functions  and  hyperbolic  tri- 
gonometric functions.   For  instance,  the  function  for  hyperbolic  tangent  has 
the  entrypoint  TANH6U  and  its  code  file  name  is  I^LIB/TANH6^.   Furthermore, 
it  expects  a  REAL  parameter  in  RGA  and  returns  its  REAL  result  in  RGA. 
Therefore,  to  call  it  from  a  GLYPNIR  program,  the  external  entry  declaration 
must  be  included: 

EXTERNAL  PREAL  SUBROUTINE  HTAN  AS  RGA 

(PREAL  X  AS  RGA) 

ENTRY  =  TANH6U 

FILENAME  =  "1ULIB/TANH6U"; 
Thereafter,  when  one  wishes  to  call  the  subroutine,  the  identifier  HTAN 
should  be  used.   If  the  ZIP  option  is  in  effect,  the  programmmer  must  see 
that  the  file  is  present  on  disk  when  the  files  are  collected. 


2.7  Linkage  to  the  System-Trigonometric  Subroutines 

Calls  on  the  square  root,  natural  log,  exponentiation,  and  trigo- 
nometric functions  are  now  handled  intrinsically  in  GLYPNIR.   Those  routines 
are: 


Subroutine  Name 

SIN 

COS 

TAN 

COT 

ARCTAN 

LN 

EXP 


Function 

sine 

cosine 

tangent 

cotangent 

arctangent 

natural  log 

exponential 
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Subroutine  Name  Function 

SQRT  square  root 

Use  of  these  identifiers  will  result  in  appropriate  calls  and  no 
declarations  for  the  subroutines  need  appear  in  the  program.   GLYPNIR  prog- 
rams accomplishing  linkages  to  the  routines  in  the  old  fashion  -will  still 
work. 

2.8  Control  Cards  and  Use  of  the  ZIP  Option 

To  compile  a  subroutine  with  GLYPNIR,  the  B6500  control  cards 
should  be  the  same  as  those  used  in  a  main  program.   If  the  GLYPNIR  option 
ZIP  is  used,  the  subroutine  will  automatically  be  assembled.   The  conventions 
for  naming  the  output  files  of  GLYPNIR  and  ASK  are  as  follows: 

for  #C0MPILE  identifier  l>/<identifier  2>  WITH  GLYPNIR,  the  ASK 
code  file  which  GLYPNIR  generates  will  be: 

identifier  l>/GLYPSUB/<sub routine  narae> 
where  <subroutine  name>  is  the  name  of  the  subroutine  being  compiled;  and 
if  the  ZIP  option  is  used,  the  output  of  ASK  will  be: 

<identifier  l>/< sub routine  name>. 

For  example,  if  a  GLYPNIR  subroutine  named  ALPHA  were  compiled 
with: 

#COMPILE  A/B  WITH  GLYPNIR  FOR  LIBRARY  then  GLYPNIR  would  produce: 

a/glypsub/alpha 

and  ASK  would  produce: 

A/ ALPHA. 

It  is  the  assembled  code  file  produced  by  ASK  which  must  be  speci- 
fied if  the  <filename  part>  in  the  external  entry  declaration  in  the  main 
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program  is  used.   If  ZIP  is  used  when  compiling  a  main  program  having  exter- 
nal entry  declarations  with  specified  filenames,  GLYPNIR  will  generate  the 
necessary  control  cards  to  assemble  the  main  program,  invoke  the  collector 
and  then  the  loader.   At  the  collector  stage,  all  subroutine  code  files 
specified  in  the  entry  declarations  will  be  collected  along  with  the  main 
program  and  the  system  trigonometric  routines,  log  routines,  etc.,  if  they 
are  called  in  the  program. 
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3 .   IMPLEMENTATION 

3.1  Some  General  Comments  on  the  GLYPNIR  Compiler 

GLYPNIR  is  a  one-pass  compiler  which  utilizes  the  University  of 
Illinois  Translator  Writing  System.   It  runs  on  the  B65OO,  and  output  from  the 
compiler  is  ILLIAC  IV  assembly  language.   Lawrie  and  Layman  [3]  provide  a  basic 
introduction  to  the  structure  and  internal  workings  of  the  compiler  and,  for 
the  most  part,  the  author  will  not  attempt  to  duplicate  that  information  here. 

However,  a  topic  of  great  importance,  the  way  in  which  GLYPNIR 
manages  the  user-declared  variables,  must  be  thoroughly  understood  before  a 
discussion  of  subroutines  can  begin.   Variables  and  vectors  are  assigned  space 
in  PE  memory  in  three  distinct  sets,  a  PE  memory  stack,  a  CU  memory  stack 
and  a  Boolean  memory  stack.   Allocation  is  done  at  compile  time  and  all  assign- 
ments are  made  on  a  stack  basis.   PE  variables  are  assigned  storage  relative 
to  the  ASK  label  contained  in  the  alpha  variable  PNAME  (CNAME  for  CU  variables, 
and  BNAME  for  Boolean  variables) .   In  a  main  program  the  names  of  these  stacks 
are  "PREG, "  "CREG"  and  "BREG"  respectively.   For  an  external  GLYPNIR  subroutine, 
the  stack  names  are  constructed  by  appending  the  first  five  or  fewer  charac- 
ters of  the  subroutine  name  to  the  letters  P,  C  and  B.  Variables  declared  in 
common  blocks  are  assigned  to  their  own  stacks,  the  names  of  which  are  con- 
structed in  the  same  fashion  as  the  principal  memory  stacks  of  external  sub- 
routines.  The  systematic  way  in  which  these  stacks  are  named  provides  the 
compiler  with  a  method  for  communicating  data  among  separately  compiled  seg- 
ments via  parameters  and  common  storage  areas. 
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3.2  Description  of  Compiler  Tables 

Wo  new  tables  were  added  to  GLYPNIR  in  the  process  of  implementing 
external  subroutines  but,  in  some  cases,  more  extensive  use  of  existing  tables 
was  made.   The  tables  relevant  to  this  discussion  are: 
BTGTAB: 

This  array  contains  all  identifiers  and  strings  appearing  in  a 
program.  Each  entry  for  an  identifier  also  contains  a  pointer  to  IDTAB. 
IDTAB: 

This  array  is  used  to  hold  semantic  information  associated  with 
identifiers.   Each  identifier  has  a  two-word  entry  in  IDTAB,  the  first  con- 
taining information  about  what  entity  is  represented,  its  type,  etc.   If  the 
entity  is  a  subroutine  or  function,  the  second  word  is  subdivided  into  three 
fields: 

[U6:2]  -  SUBDISPF  -  which  indicates  whether  the  subroutine  is  inter- 
nal (contains  0)  or  external  (contains  1) 

[M+:29]  -  PARAMLINKF  -  which  contains  a  pointer  to  the  array  PADLAR 

[15:16]  -  LABF  -  which  contains  a  label  number  at  which  executable 
subroutine  code  begins  if  internal;  otherwise,  it  contains  zero.  ' 
PADLAR: 

This  is  the  principal  array  used  in  holding  information  about  sub- 
routines.  Every  subroutine  declared  is  assigned  a  row  of  PADLAR  and,  within 
that  row,  there  is  one  word  of  information  about  each  parameter  and  about  the 
subroutine  itself,  if  it  is  a  function.   If  the  subroutine  is  external,  the 
first  word  in  the  row  contains  the  first  five  characters  of  the  subroutine 
name  in  [29:30].   Otherwise,  each  word  is  subdivided  into  the  following  fields: 

[U6:U]  -  TYPEF  -  which  is  the  type  of  parameter  or  function 
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[38:1]  -  VALUEF  -  which  is  used  to  indicate  an  output  parameter 
[35: 16]  -  PARAMLOCF  -  which  is  relative  address  of  a  parameter  to 

the  base  of  its  associated  variable  memory  stack 
[16:6]  -  REGCONDF  -  which  indicates  where  a  parameter  is  to  be 

stored  (i.e.,  in  a  register  or  in  a  variable  memory  stack) 
Remember  that  the  disposition  of  the  subroutine  (internal  or  exter- 
nal) is  contained  in  the  IDTAB  entry  for  the  subroutine  identifier  and  the 
contents  of  the  PADLAR  row  will  be  treated  according  to  the  disposition. 

3.3  The  Declaration 

Processing  of  the  subroutine  declaration  or  external  subroutine 
entry  declaration  in  GLYPNIR  consists  of  setting  the  parameters  in  the  IDTAB 
entry  for  the  subroutine  identifier,  filling  the  assigned  PADLAR  row  with  the 
appropriate  information  and,  in  the  case  of  the  internal  subroutine,  compiling 
the  body  of  the  subroutine. 

3»3«1  The  Internal  Subroutine  Declaration 

When  an  internal  subroutine  declaration  is  encountered,  the  compiler: 

1.  Determines  whether  a  function  or  subroutine  is  present. 

2.  Assigns  a  row  in  PADLAR  to  the  subroutine. 

3.  Processes  the  subroutine  identifier.  A  storage  space  for  the 
function  value  is  assigned  and  the  first  word  of  the  PADLAR  row  is  filled  with 
the  necessary  information  on  the  function  type,  etc. 

k.      Generates  a  branch  around  the  body  of  subroutine  code.   All 
internal  labels  generated  by  GLYPNIR  are  of  the  form  Gn,  where  n  is  determined 
by  the  compiler.   The  compiler  assigns  a  label  number  which  will  appear  at  the 
end  of  the  subroutine  code  and  that  number  is  stored  so  that  the  appropriate 
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ASK  label  can  be  generated  following  compilation  of  the  subroutine. 

5-   Generates  a  label  marking  the  point  at  which  subroutine  code 
begins,  and  then  generates  code  for  storing  the  return  address  on  a  stack. 
This  stack  is  maintained  during  execution  time;  the  return  addresses  are 
stacked  so  that  nested  subroutine  calls  can  be  performed. 

6.  Processes  formal  parameters.   For  each  parameter  the  next  word 
in  the  PADLAE  row  is  filled  with  the  following  information: 

a.  type 

b.  call -by-name  (OUTPUT)  or  call-by-value  parameter 

c.  relative  address  of  parameter 

d.  storage  condition  (in  a  register  or  in  a  variable  stack) 

7.  Puts  a  zero  into  the  next  PADLAR  word  to  mark  the  end  of  the 
parameter  list. 

8.  Compiles  the  body  of  the  subroutine. 

9.  Generates  a  return  to  address  contained  in  the  top  of  the  return 
address  stack. 

10.  Generates  the  label  saved  in  Step  k. 

11.  Determines  the  maximum  amount  of  PE,  CU,  and  Boolean  storage 
subroutine  uses.   (See  Section  5. 1.1  of  Lawrie  and  Layman  [3]  for  a  discussion 
of  storage  allocation  processes.) 

3«3'2  The  External  Subroutine  Entry  Declaration 

The  compiler  takes  the  following  steps  upon  encountering  an  exter- 
nal subroutine  entry  declaration: 

1.  Determines  whether  a  function  or  subroutine  is  present. 

2.  Assigns  a  row  in  PADLAR  to  the  subroutine. 
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3.   Processes  the  subroutine  identifier.   It  takes  the  first  five 
characters  and  places  them  in  the  first  word  of  the  PADLAR  row.   Then,  if 
the  subroutine  is  a  function,  it  places  type  and  location  information  in  the 
second  word. 

h.      Processes  the  formal  parameters.   For  each  parameter  the  next 
word  in  the  PADLAR  row  is  filled  with  the  following  information: 

a.  type 

b.  call-by-name  or  call -by-value 

c.  relative  address  of  parameter 

d.  storage  condition 

If  the  parameter  is  stored  in  the  PE,  CU,  or  Boolean  memory  stack,  the  relative 
address  indicates  an  offset  from  the  base  of  the  subroutine  stack,  not  the 
stack  of  the  calling  program.   In  the  compilation  of  an  external  GLYPNIR  sub- 
routine, the  parameters  specified  in  the  subroutine  heading  are  treated  simply 
as  the  first  variables  declared  in  the  program  and  are  therefore  assigned  the 
first  locations  of  their  respective  stacks.   In  this  way,  the  compiler  can 
determine  the  relative  addresses  of  the  parameters  in  the  external  entry  dec- 
laration. 

5-   Puts  a  zero  into  the  next  PADLAR  word  to  mark  the  end  of  the 
parameter  list. 

6.   If  <entry  part>  is  present,  the  following  actions  are  taken: 
a.   The  compiler  generates  the  ASK  speudo-ops: 
EXTERNAL  <entrypoint>; 
DEFINE  <internal  entry  name>  =  <entrypoint>##;  where 

<entrypoint>  is  the  user- specified  entry  label  and  <internal  entry 

name>  is  the  entry  label  the  compiler  would  automatically  generate 
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for  a  GLYPNIR  external  subroutine. 

b.   The  compiler  checks  to  see  that  all  parameters  have  been 

declared  AS  registers  and  generates  an  error  if  this  is  not  the 

case. 
Thereafter,  any  calls  on  this  routine  look  like  a  call  on  a  GLYPNIR  external 
subroutine  to  the  compiler.   The  DEFINE  generated  and  the  restrictions  on  the 
parameters  allow  the  correct  linkage  to  occur  despite  the  compiler's  gener- 
ating a  call  on  a  GLYPNIR  subroutine. 

7-   If  <filename  part>  is  present,  the  compiler  saves  a  pointer  to 
the  BIGTAB  location  of  the  string  containing  the  name  of  the  file  in  which  is 
contained  the  subroutine  executable  code.   This  information  is  used  when  the 
collect  control  deck  is  built. 

8.   If  the  subroutine  is  a  GLYPNIR  program  (<entry  part>  was  not 
present),  the  compiler  generates  ASK  external  declarations  for  the  entry-point 
label,  and  the  base  of  the  subroutines  PE,  CU,  and  Boolean  variable  storage 
stacks.   These  names  are  constructed  by  taking  the  first  five  characters  of 
the  subroutine  name  and  appending  them  to  the  letters  L,  P,  C,  and  B  respec- 
tively. 

3-h     The  Subroutine  Call 

When  the  compiler  encounters  an  identifier  which  has  an  IDTAB  entry 
indicating  it  is  a  subroutine,  it  proceeds  as  follows: 

1.  Finds  in  the  same  IDTAB  entry  the  PADLAR  row  assigned  to  the 
subroutine  and  the  subroutine  disposition  (internal  or  external). 

2.  Generates  code  to  purge  all  registers. 

3-   Proceeds  to  process  the  actualy  parameters  by  performing  any 
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conversions  required  and  by  placing  the  values  in  the  appropriate  registers  or 
memory  locations.   (The  next  section  explains  the  treatment  of  parameters  in 
detail. ) 

k.      Performs  all  null  assignments  for  actual  parameters  which  were 
empty  (including  the  case  where  there  are  fewer  actual  parameters  than  formal 
parameters) . 

5-  Generates  a  calling  sequence.   For  an  internal  subroutine  this 
consists  of  generating  a  branch  to  a  label  Gn  where  n  comes  from  the  subroutine 
identifiers  IDTAB  entry.   For  an  external  subroutine,  the  label  to  which  the 
branch  is  made  is  of  the  form  Lcccc  where  the  characters  ccccc  are  obtained 
from  the  first  word  of  the  subroutine's  PADLAR  row. 

6-  Replaces  the  values  of  call-by-name  parameters  with  the  values 
held  upon  exit  from  the  subroutine.   The  process  is  identical  to  the 
assignment  of  parameter  values  but  in  a  reverse  direction. 

7-  If  the  subroutine  is  a  function,  the  function  value  (or  values 
if  a  PE  function)  is  assigned  to  a  location  where  the  calling  program  can 
access  it. 

3.5  The  Treatment  of  Parameters  in  Subroutine  Linkage 

Setting  up  the  linkages  to  subroutines  is  fairly  simple,  but  passing 
the  values  of  parameters  is  quite  another  matter.  Actual  parameters  can  be  of 
three  types:   simple  variables,  parameter  expressions,  or  empty  (including 
omitted  trailing  parameters).   Only  simple  variables  can  be  used  as  call-by- 
name parameters;  if  one  of  the  other  types  is  used  for  a  call-by-name  para- 
meter, the  actual  parameter  will  be  treated  as  a  call-by-value  only  for  that 
subroutine  call. 
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Extensive  policing  for  register  misuse  is  conducted  during  the 
parameter  value  assignment  portion  of  a  subroutine  call.   The  compiler  moniters 
the  usage  of  registers  RGA,  RGB,  RGR,  RGS,  RGX,  ACAR1,  ACAR2,  and  ACAR3-   In 
the  process  of  assigning  parameter  values,  when  one  of  these  registers  is 
used  to  store  the  value  of  a  parameter,  it  is  marked  in  use.   If  the  compiler 
later  needs  that  register  to  perform  a  conversion  or  another  assignment,  an 
error  condition  is  detected. 

The  bulk  of  the  work  in  parameter  conversion  and  assignment  is  done 
by  the  procedure  PARAMCONVERASS.   Variables  global  to  it,  which  are  set  before 
it  is  called,  indicate  the  locations  of  the  source  and  destination  of  the 
parameter  value  and  the  respective  types.   PARAMCONVERASS  then  generates  all 
the  necessary  code  to  see  that  the  parameters  are  converted  to  the  expected 
type  and  assigned  to  the  correct  location.   Furthermore,  it  moniters  register 
usage  in  parameter  storage  and  checks  for  register  misuse  for  each  parameter. 

When  the  source  location  is  one  of  the  variable  memory  stacks, 
PARAMCONVERASS  assumes  the  stack  to  be  the  primary  PE,  CU,  or  Boolean  memory 
stack  of  the  program  (e.g.,  PREG,  CREG,  or  BREG  for  a  main  program).   For  a 
destination  in  one  of  those  stacks,  the  assignment  is  made  to  that  same  stack 
if  the  subroutine  is  internal.   For  an  external  subroutine,  the  assignment  is 
made  to  a  location  relative  to  the  base  of  one  of  the  subroutine's  primary 
memory  stacks.   To  determine  the  name  of  the  stack  base,  the  five  characters 
in  the  first  word  of  the  PADLAR  row  are  appended  to  P,  C,  or  B,  depending  on 
the  parameter  type.   If  the  source  is  a  variable  declared  in  a  common  block, 
PARAMCONVERASS  will  reference  the  correct  location;  in  no  instance  will  the 
destination  be  in  a  common  storage  area. 

For  replacing  the  values  of  call-by-name  parameters,  PARAMCONVERASS 
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is  once  again  used  to  generate  the  code  for  assigning  the  values  to  the  cor- 
rect location  and  performing  any  required  conversion;  potential  register  misuse 
is  once  again  checked. 

3.6  Compilation  of  the  External  Subroutine 

The  external  subroutine  is  compiled  in  exactly  the  same  fashion  as 
a  main  GLYPNIR  program,  except  at  two  critical  points. 

In  processing  the  subroutine  heading,  the  compiler  must  undergo 
initial  preparation  for  compiling  the  program.   First,  from  the  subroutine 
identifier  it  constructs  the  entrypoint  name  and  the  names  of  the  three  prin- 
cipal memory  stacks.   At  this  point,  code  is  generated  for  pushing  the  return 
address  onto  the  return  address  stack.   If  the  subroutine  is  a  function,  the 
subroutine  identifier  is  treated  in  the  same  fashion  as  a  simple  variable  of 
the  same  type  (i.e.,  an  IDTAB  entry  is  constructed  for  it,  a  storage  location 
is  assigned,  etc.)   The  same  is  true  of  the  parameters  specified.   From  the 
compiler's  point  of  view,  the  subroutine  heading: 

SUBROUTINE  S  (PREAL  X,  CINT  CI,  BOOLEAN  B,  PREAL  Y); 
is  equivalent  to: 

SUBROUTINE  S; 
BEGIN 

PREAL  X,  Y; 
CINT  CI; 
BOOLEAN  B; 

Finally,  a  pointer  to  the  BIGTAB  location  of  the  subroutine  identi- 
fier is  saved  for  use  in  constructing  a  file  name  if  a  control  deck  for  the 
collector  is  to  be  built. 
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The  other  point  at  which  compilation  differs  is  at  the  end  of  the 
program.   A  subroutine  return  is  generated  as  the  last  exacutahle  instruction. 
Furthermore,  the  code  appearing  at  the  beginning  of  the  ASK  code  file  differs 
substantially  from  that  produced  for  a  main  program.   A  good  deal  less  ini- 
tialization is  done  and  many  of  the  identifiers  designating  storage  areas 
declared  in  the  main  program  are  simply  declared  external. 

3.7  Common  Storage 

In  order  to  implement  common  storage  facilities,  three  bits  were 
added  to  the  location  field  in  the  IDTAB  entries  for  identifiers  residing  in 
one  of  the  memory  stacks.   The  low-order  bits  still  contain  the  address  of  the 
variable  relative  to  its  stack  base  and  the  upper  three  bits  contain  an  index 
indicating  which  stack  is  referenced.   A  zero  in  the  top  three  bits  indicates 
an  address  relative  to  the  principal  memory  stacks  (e.g.,  PREG,  BREG,  or  CREG 
for  a  main  program).   Otherwise,  it  indicates  an  address  relative  to  the  base 
of  a  common  storage  area.   In  this  case,  those  bits  serve  as  an  index  to  an 
array  containing  the  labels  of  the  stack  bases.   The  value  of  the  location 
field  is  assigned  at  the  time  of  the  declaration  of  the  variable  and  never 
requires  alteration.  When  the  compiler  generates  code  referencing  a  quantity 
in  a  stack,  it  strips  off  the  top  three  bits  to  determine  which  stack,  and 
uses  the  remainder  of  the  field  as  the  relative  address. 

When  a  common  block  declaration  is  encountered,  the  compiler  pro- 
ceeds thusly: 

1.  Saves  the  values  of  the  storage  allocators  for  the  principal  PE, 
CU,  and  Boolean  stacks  and  sets  the  allocators  to  zero. 

2.  Assigns  an  index  to  the  common  storage  block  (from  1  to  7) . 
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3-   Takes  the  first  five  characters  of  the  block  name  and  constructs 
the  base  labels  of  the  PE,  CU,  and  Boolean  storage  for  the  block  by  appending 
those  characters  to  P,   C,  and  B.   If  the  block  is  unnamed,  it  assigns  the 
default  labels  PCOMMN,  CCOMMN,  and  BCOMMN.   It  then  places  these  labels  in  the 
array  containing  the  common  block  base  names. 

k.      Processes  the  variable  declarations  in  the  usual  fashion  but 
puts  the  block  index  in  the  top  bits  of  the  location  field. 

5.  When  ENDCOMMON  is  reached,  it  saves  the  values  of  the  storage 
allocators  for  use  in  making  the  ASK  declarations  for  the  storage  blocks, 
and  restores  the  values  the  allocators  held  before  the  common  block  began. 

If  the  program  is  a  main  program,  the  compiler  generates  the  ASK 
declarations  for  each  base  label  and  the  corresponding  number  of  words  or  rows 
in  its  block.   Otherwise,  it  declares  the  base  labels  external. 

3.8  Linkage  to  the  System  Trigonometric  Routines  and  the  GLYPNIR  Dynamic 
Storage  Allocation  Routine 

The  GLYPNIR  identifiers  for  the  system  trigonometric,  square  root, 
log,  and  exponentiation  routines  have  entries  in  IDTAB  and  PADLAR  which  are 
initialized  before  program  compilation  begins.   The  values  of  the  initialized 
entries  are  the  same  as  if  an  external  entry  declaration  had  been  made  for 
that  subroutine.   For  instance,  initialization  is  made  for  the  identifier  SIN 
identical  to  the  IDTAB  and  PADLAR  entries  the  compiler  would  make  if  it  were 
to  process: 

EXTERNAL  PREAL  SUBROUTINE  SIN  AS  RGA  (PREAL  ARG  AS  RGA)  ENTRY  =  SIN6U; 
If  any  of  these  routines  are  called  during  the  program,  the  compiler  sets  a 
flag  so  that  their  code  files  can  be  included  in  the  collect  deck. 

The  GLYPNIR  dynamic  storage  allocation  routines  also  have  initialized 
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entries  which  make  them  look  like  external  subroutines.   The  code  responsible 
for  performing  dynamic  storage  allocation  resides  in  GLYPNIR/ EXTHEAD  which  is 
always  collected  with  the  main  program.   In  the  past  they  were  treated  like 
internal  subroutine s,  but  this  did  not  allow  access  to  them  by  external  GLYPNIR 
subroutines;  therefore,  modifications  were  made.   Since  the  allocation  algo- 
rithms depend  upon  knowing  the  last  address  of  the  main  program  in  order  to 
assign  memory  for  dynamic  storage,  it  is  critical  that  the  GLYPNIR  main  prog- 
ram be  the  last  file  specified  in  the  collector  control  deck. 

3.9  Linkage  to  Non-GLYPNIR  External  Subroutines 

Setting  up  linkages  to  non-GLYPNIR ■ subroutines  is  a  trivial  matter. 
By  restricting  the  specification  of  all  parameters  to  AS  registers,  the  com- 
piler can  treat  a  call  on  the  subroutine  as  a  call  on  a  GLYPNIR  external  sub- 
routine, since  no  reference  will  be  made  to  a  subroutine's  variable  memory 
stack  when  parameter  values  are  passed.   Therefore,  when  an  external  entry 
declaration  specifying  ENTRY  =  <identifier>  is  compiled,  instead  of  generating: 

EXTERNAL  Lccccc,  Pccccc,  Cccccc,  Bccccc; 
as  it  would  for  a  GLYPNIR  subroutine,  the  compiler  generates: 

EXTERNAL  <identifier>; 

DEFINE  Lccccc  =  <identifier>##; 
Thereafter,  when  the  routine  is  called,  the  compiler  will  act  as  if  it  were 
linking  to  a  GLYPNIR  external  subroutine,  but  will  automatically  perform  the 
correct  linkage. 


37 

h.      CONCLUSION 

Facilities  have  been  provided  in  GLYPNIR  which  allow  the  separate 
compilation  of  GLYPNIR  subroutines  that  can  be  called  from  GLYPNIR  programs. 
It  is  also  possible  for  GLYPNIR  programs  to  call  ASK  subroutines  specified  in 
a  standard  fashion. 

One  possible  extension  of  the  work  already  completed  is  allowing  more 
than  one  subroutine  to  be  compiled  in  a  single  run.   This  would  involve  only  a 
minor  change  in  the  syntax  but  would  require  a  fairly  tedious  reintialization 
of  the  compiler  for  each  subroutine.  Another  possible  extension  would  be 
an  option  of  compiling  GLYPNIR  subroutines  in  such  a  manner  that  they  can  be 
called  from  other  languages.   GLYPNIR  subroutines  are  compiled  in  such  a  way 
that  they  rely  on  certain  storage  declarations  and  sections  of  code  included 
with  all  main  programs.   To  put  this  option  into  effect,  these  declarations 
and  code  blocks  would  have  to  be  included  with  the  subroutines,  and  a  slightly 
different  linkage  mechanism  would  have  to  be  provided. 
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APPENDIX  A 
THE  SYNTAX  OF  SUBROUTINES 

The  syntax  given  here  for  subroutines  is  a  portion  of  the  entire 
syntax  for  GLYPNIR  as  input  to  the  translator  writing  system-   The  syntax  is 
specified  in  a  form  similar  to  BNF,  but  there  are  certain  differences  which 
facilitate  processing.   The  reader  should  refer  to  Trout  [5]  for  an  explana- 
tion of  this  form  of  specification. 


SYNTAX  OF  GLYPNlR  SUBROUTINES 


1+0 


r«TYPE*  AHEAD  SUBROUTINE]* 
[SUBR0uTlNt/PR0CE0UREPs30  1#S206 


"PROGRAM"! I.. 

PS13   1 

t"*l"  NOT  AS  9S207    /    "*i"  aS  "*l"  #S20^3 
t  ["XFORMAL  PARAMETER  PART"]! 

C"  "  AHEAO  #|  /  C"ANY"  BUT  #>)*PS208  J  #|3 

"unlabelled  block*   c,/"  "  *si<n       / 

C"ANY"  BUT  BEGIN  BUT  *}     J*CL0SE  "UNLABELLED  BLOCK" 
[#/"  "^Sl^I  /  C"  "J  *S?4  *S13  PS15  I 

"XF0RMAl.  PARAMETER  PaRT"M« 

(  ILIST  {"TYPE"  [  [UUT*S209H 

t«*I"  NOT  AS 
LISTCWANY"  BUT  # 


IbANyw 
U/"   " 


BUT    )    BUT    #M*    PS2113 
AHEAD    #1    PS2123I 


HS210/«*I«    AS    »*I"    PS210J3/ 
BUT    )    BUT    tUCLOSE    i52UJ 

sepaRatok  •  ' 


"SUBRqUTINE  DECLARATION"! »■ 

cl"type"  /"any"  but  subroutine  but  procedure  rut  #>  but  #end 

ahead  subroutine  psah 
csubroutine  /  procedure  *s303  ps353  c"*i"  not  as  ps31  / 

"*j"    As    "*I"    *S3lJ 
[["FORMAL    PARAMETEK    PART"H#MpS36 
C"UNLABELLED    STATEMENT"&]PS37    i 

•exteRna»-  subr0Utine  entry  declaration"! »■      exteRnaL^oi 

C   ["TyPE"/"ANY"  BUT  SUBROUTINE  BUT  PROCEDURE  BUT  #* 

BUT  #END  AHEAD  SUBROUTINE  PS43I 
CSUBROuTlNE/PROcEnuHEPS303   PS353 
l"*I"  NOT  AS  PS202/  "M"  AS  **I"  PS202] 
C  t  C"FORMAL  PARAMETER  PART"3*  (iS36 

tENTRY«"*I"  PS2033&  CFILENAME«"*S"  *S204]&  3  / 

C"ANY"  BUT  #|J*  PS34J    PS205) 


"FORMAL  PARAMETER 
([LIST  f"TYPE" 


U/" 


PART^im 

ttOUTH  "*I*  NOT  AS  PS32/ 

C0UT3&  "*I"  AS  "*I"  PS323/ 
LlsTCwANY"  BUT  »  BUT  )  BUT  #|]CLOSE  PS33J 
["ANY"  BUT  )  BUT  #I]*»S33] 
"  AHEAD  tt    PS34  ]| 


SEPARATUR  #/ 


in 

APPENDIX  B 
SAMPLE  EXTERNAL  SUBROUTINES 

Three  programs  are  presented  "below:   a  GLYPNIR  separately  compiled 
subroutine,  an  ASK  subroutine,  and  the  GLYPNIR  main  program  which  calls  them. 
Although  the  programs  are  not  complex,  they  should  serve  to  illustrate  the 
critical  areas  in  external  subroutine  use. 

The  GLYPNIR  function  ARRAYMAX  finds  the  elements  of  maximum  magni- 
tude in  each  row  and  each  column  of  an  array  of  order  n  <  Sk   which  is  stored 
straight,  and  returns  the  value  of  the  element  of  maximum  magnitude  of  the  array 
as  its  function  value.   The  array  is  passed  to  the  subroutine  and  the  subroutine 
returns  the  row  maximums  via  common  storage;  the  column  maximums  are  returned 
as  a  parameter.   It  is  assumed  that  only  the  first  n  PE's  are  enabled  at  the 
time  of  the  call. 

The  ASK  subroutine  evaluates  the  function  f(x)  =  x  +  12 x  +  "J.      Its 
REAL  argument  is  passed  in  RGA  and  it  returns  its  function  value  in  RGA. 


k2 


CREAL  SUBROUTINE-  ARR  a  YMAX  (  C  I  NT  ORUER.PREAL  CnLUMN*AX)| 
PEGIN 

COMMON  ArEAU 

PREaL  VECTOR  ARRAYC63]; 
CREAL  VECTOR  RnwMAX[63)J 
ENUCOMMONJ 
CI^T  INDFX; 
* 
%    CALCULATE  ROW  MAXIMUMS 

t 

LOUR  iNDEXlaO.l.f  nRUEH-1  )  "iO 

Rn^MAyC INDEX! l=MAXCABS(ARRAY[INoEX]))| 


%    CALCULATE  COLUMN  MAXIMUMS 
1 

COLUMNMAyrsO.Oj 

lour  Index j=o#i,(nROER-l )  no 

IF    A8S(  AKKAYt  iNHtX]  )    GTR    cOLljMNMAX    THEN 
COLUMNMAXtaABS( ARRAY! INDEX! )l 

ARKAYMAXt=MAX(COLllMNMAX); 
END. 


U3 


ask  function  fqp  r(X)  i«  x**3  ♦  i2.o*x  ♦  7.0 


rsTARICENTHyli «FILL  * 


LUP 

MLRN 

MLRN 

LOs 
L<>  A 
LlT(l) 

mlrn 
aurn 

L I T  C  1  ) 

ADRN 

STLC  3^ 


SA| 
SRI 
SRI 
SAI 

SRI 
■12.0* 

sci  1 

SSI 

■7,01 
Sri  i 

SICRI 


kk 


*  GLYKiMlK  MaIN  PROGRAM 
REGlN 

PRLAL  X»YJ 
COMMON  ArEAIj 

PREaL  VECTOR  ?  f  6  3  }  ; 

creal  vector  rowmax[63]l 
enucommonj 

CRLAL  CX I 


external  creal  subroutine  arraymax 

(clnt  dimension.  preal  out  columnmax); 

External  preal  surruutine  f  as  rga 

(PREA(_  ARfi  AS  Rr,A) 
ENTRYaFSTART J 


CX»»ARrAyMAX(64,X) i 
Yl»F(X)> 


* 
ENO. 


APPENDIX  C 
NOTES  ON  PASSING  VECTORS  AS  PARAMETERS 

Vectors  can  be  passed  to  external  GLYPNIR  subroutines  in  the  same 
way  that  they  are  passed  to  internal  subroutines.   The  following  excerpt  from 
Layman  [k]    describes  this  method: 

This  final  problem  concerns  the  use  of  vectors  in  and  as  parameters 
for  subroutines.   There  are  two  basic  types  of  parameters- -"CALL  BY  VALUE"  and 
"CALL  BY  NAME."  In  GLYPNIR  the  latter  type  is  indicated  by  including  "OUT"  in 
the  parameter  specification.   Actual  parameters  corresponding  to  CALL  BY  VALUE 
formal  parameters  may  be  any  expression,  including  subscripted  vectors. 

But  subscripted  vectors  may  not  be  used  as  CALL  BY  NAME  parameters. 
To  get  the  same  effect  as  passing  vectors  "BY  NAME"  one  can  do  as  follows: 

a)  For  each  vector  quantity  that  you  want  to  pass  "BY  NAME"  include 
an  output  parameter  of  type  POINTER  in  subroutine  declaration 
(PC POINT  for  PE  vectors,  CNP0INT  for  CU  vectors). 

b)  When  calling  the  SUBROUTINE,  pass  just  the  vector  identifier  in 
the  place  corresponding  to  the  output  POINTER  quantities. 

c)  Within  the  subroutine  itself  you  may  use  the  POINTER  parameter 
just  as  though  it  had  been  declared  as  a  vector. 


Example : 


BEGIN 

PE  REAL  VECTOR  VI,  V2   [5]; 

PE  REAL  X,  Y; 
SUBROUTINE  SUBB  (PCPOINT  OUT  PI,  PCPOINT  OUT  P2,  PREAL  A) 
BEGIN 


k6 

PI  [1]     P2  [h]  .5; 

A  PI  [1]     P2  [k]      • 
P2  Ik}  PI   [2]      A; 

END; 

SUBB  (VI,  V2,  X); 
END 
The  compiler  actually  treats  the  quantities  PI  [1],  P2  [k]   etc.  as  if  you 
had  done  the  following: 

REAL  FIELD  R  [0,  FULL]; 
PCPOINT  PI,  P2; 

PI.   [1]  R     P2.  [h]   R        .5;    etc. 
That  is  it  treats  them  as  special  forms  of  field  content  designators.   This 
short  form  may  be  used  anywhere  in  GLYPNIR  programs  also.   One  final  note,  this 
trick  only  works  for  REAL  vectors. 
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